@abdul99ahad This looks amazing! From what I can see:

• We now have an additional layer of validation, for situations marked as deprecated.
• During validation we can pick up such properties, and i.e. turn them into schema warnings and or problems in the problems panel.

I'd consider if/how we could use stock deprecation support in the schema (https://json-schema.org/draft/2020-12/json-schema-validation#section-9.3) over writing our own implementation.

I'd consider if/how we could use stock deprecation support in the schema (https://json-schema.org/draft/2020-12/json-schema-validation#section-9.3) over writing our own implementation.

That's doable, the only downside is to check for warnings ,we can't integrate it with ajv validator but have to rely on recursively checking the schema after the validation to warn the user.

I explored the stock deprecated: true support as suggested instead of using the isDeprecated keyword we introduced earlier.

However, using the stock approach complicates warning users. Since deprecated is purely metadata, there’s no built-in mechanism in AJV to emit warnings, so what we needed was to recursively walk the schema ourselves. The main issue with this is we lose context: we end up getting warnings for all deprecated fields across the schema, not just the ones used in the current template being validated.

In contrast, our isDeprecated keyword allowed us to precisely warn only for properties actually present in the template under validation, without needing to do a full tree walk.

In my opinion, introducing a custom keyword like isDeprecated to explicitly mark deprecated properties makes more sense for our use case, it keeps validation scoped and predictable. We already have custom errors support, so adding custom warning doesn't deviate from current pattern.

Happy to discuss alternatives or hybrid approaches if needed.

@barmac this PR needs a new owner.